Language/OS - Multiplatform Resource Library/LANGUAGE OS.iso/sr/info.lha/info-sr.1990

Text File | 1993-07-24 | 32KB | 780 lines

From gmt  Wed Jan  3 10:27:20 1990
Date: Wed, 3 Jan 90 10:27:20 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu (5.59-1.7/15)
    id AA22646; Wed, 3 Jan 90 10:27:20 MST
To: info-sr
Subject: The SR project has moved

The SR project's home machine, formerly "arizona.edu", has changed its
Internet domain name to "cs.arizona.edu".  The uucp sitename of "arizona"
has not changed.

FTP files from:            cs.arizona.edu
                (128.196.128.118 or 192.12.69.1)

Send questions to:        [e-mail]
                uunet!arizona!sr-project

Mailing list contributions:    [e-mail]
                uunet!arizona!info-sr

Changes of address:        [e-mail]
                uunet!arizona!info-sr-request

From ntmtv![e-mail]  Fri Mar  2 15:37:24 1990
From: ntmtv![e-mail]
Received: from ames.arc.nasa.gov by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP
    id AA03203; Fri, 2 Mar 90 15:37:24 MST
Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 2 Mar 90 14:34:55 -0800
Received: by ntmtv.com (3.2/SMI-3.2)
    id AA07762; Fri, 2 Mar 90 13:56:26 PST
Date: Fri, 2 Mar 90 13:56:26 PST
Message-Id: <[e-mail]>
To: ames![e-mail], ames![e-mail]

Received: from alpet.ntmtv.com by ntmtv.com (3.2/SMI-3.2)
    id AA07755; Fri, 2 Mar 90 13:56:23 PST
Received: by alpet.ntmtv.com (4.0/SMI-4.0)
    id AA01732; Fri, 2 Mar 90 13:54:31 PST
Date: Fri, 2 Mar 90 13:54:31 PST
From: hildum@alpet (Eric Hildum)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Porting SR to a Motorola System V/68
Cc: [e-mail]


I am currently working on porting SR to a Motorola System V/68,
which is a 68000 family, AT&T System V release 3 version 0 Unix box.

I would like to know:

A. Has anyone done a similar port, or is working on a similar port?

B. How can I do this port such that it will be useful to other users
   of the SR language.

C. Suggestions, comments, and hints as to what to watch out for, how
   to change things, etc.

I have discovered that the C compiler and lint are more limited on
this machine.  What compiles without trouble, and passes lint on a
Sun3 with K&R C does not compile correctly (enumeration type clashes
on operator =; cpp seems to have a problem as well), nor does lint
operate (failures including the .h files). I think I am running into
hidden limits in the C compiler. Confirmation and suggestions are most
welcome...


                Eric Hildum
                Northern Telecom, Mountain View
                ntmtv![e-mail]
                [e-mail]
                [phone]

From gmt  Mon Mar  5 11:29:19 1990
Date: Mon, 5 Mar 90 11:29:19 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by megaron.cs.arizona.edu (5.59-1.7/15)
    id AA09470; Mon, 5 Mar 90 11:29:19 MST
In-Reply-To: <[e-mail]>
To: info-sr
Subject: Re:  Porting SR to a Motorola System V/68
Cc: ntmtv![e-mail]

    From ntmtv![e-mail] Fri Mar  2 15:37:32 1990

    I am currently working on porting SR to a Motorola System V/68,
    which is a 68000 family, AT&T System V release 3 version 0 Unix box....

The file "doc/port.ms", in the SR distribution, contains my thoughts on
porting SR to a new architecture, so I won't try to repeat all of that
here.  Be sure to start with SR 1.1 (the July '89 version); it's much
more portable that SR 1.0.

The HP 9000/300 is a 68000 box using System V, so that's probably the
closest existing port.  Look for #ifdef hp9000s300 in a couple of places.

Probably the best thing you can do to help others is to mail problem reports
back to [e-mail], so that we can try and address them in the
next version.

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    [phone]     [e-mail]     110 57 16 W / 32 13 45 N / +758m

From ssi!fanning![e-mail]  Tue Mar  6 20:35:32 1990
Received: from uunet.UU.NET by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP
    id AA22933; Tue, 6 Mar 90 20:35:32 MST
Received: from ssi.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
    id AA23625; Tue, 6 Mar 90 22:35:18 -0500
Received: from fanning.com by ssi (4.0/SMI-4.0)
    id AA20979; Tue, 6 Mar 90 17:03:47 CST
Received: by fanning.com (4.0/SMI-4.0)
    id AA00766; Tue, 6 Mar 90 17:03:39 CST
Date: Tue, 6 Mar 90 17:03:39 CST
From: ssi!fanning![e-mail] (Keptin Komrade Dr. Bobwrench III)
Message-Id: <[e-mail]>
To: uunet!cs.arizona.edu![e-mail]
Subject: address change

    My address is changing from uunet!ssi!fanning!rmb to uunet!ssi!rmb.
Please update the mailing list. Thanks,

    bob bownes.




From ntmtv![e-mail]  Thu Mar 22 15:36:38 1990
From: ntmtv![e-mail]
Received: from ames.arc.nasa.gov by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP
    id AA08228; Thu, 22 Mar 90 15:36:38 MST
Received: by ames.arc.nasa.gov (5.61/1.2); Thu, 22 Mar 90 14:36:44 -0800
Received: by ntmtv.com (3.2/SMI-3.2)
    id AA22326; Thu, 22 Mar 90 13:48:59 PST
Date: Thu, 22 Mar 90 13:48:59 PST
Message-Id: <[e-mail]>
To: ames![e-mail]

Received: from alpet.ntmtv.com by ntmtv.com (3.2/SMI-3.2)
    id AA22320; Thu, 22 Mar 90 13:48:55 PST
Received: by alpet.ntmtv.com (4.0/SMI-4.0)
    id AA00890; Thu, 22 Mar 90 13:46:59 PST
Date: Thu, 22 Mar 90 13:46:59 PST
From: hildum@alpet (Eric Hildum)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: SR as a distributed applications controller
Cc: Fred.Bossler.4K34@bnrmtv


I am looking into using SR as a distributed applications controller.
In this role the SR application will need to:

1. monitor the execution of a number of separate processes on one or
more hosts, initiating execution or restarting execution of the processes
should they terminate for some reason. This may involve checking dependencies
between processes (some may need to start earlier than others.)

2. allow adminstrative and maintenance control and testing of the processes
and their databases (ie, provide an interface such that the administration
and control of these processes may take place through one location).  In
addition, print and message logging services should be centralized.

3. Provide message passing, RPC, etc. services as needed between the
different processes.

Note that the other processes will be written in C, but may be linked with
library procedures as required. The processes are separate processes, and may
be updated at different times, or may not be present at all. We can probably
get away with linking at installation time, which may help with communications.

I would be interested in hearing from anybody who has done an application
like this, or has any suggestions or comments as to how it should be done.

                Thank you,
                    Eric Hildum
                    Northern Telecom
                    [phone]
                    ntmtv![e-mail]
                    [e-mail]

From [e-mail]  Tue May  1 00:21:03 1990
Received: from munnari.OZ.AU by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP
    id AA24169; Tue, 1 May 90 00:21:03 MST
Received: from batserver.cs.uq.oz (via metro) by munnari.oz.au with SunIII (5.61+IDA+MU)
    id AA08449; Tue, 1 May 1990 17:14:01 +1000
    (from [e-mail] for [e-mail])
Message-Id: <9005010442.AA14348@client>
To: [e-mail]
Subject: Casting with pointers and type sizes
Date: Tue, 01 May 90 14:42:54 +1000
From: Andrew Moran <[e-mail]>


Is it possible in SR to say ADDR(X), where X is and int and ADDR is a pointer ?

Also, what is the mechanism for finding out the size of a type ?

Angst

---------
"He's mad, totally mad.  He's madder than Mad Jack McMad, winner of last year's
 Mr. Madman competition." -- Edmund, a butler.
----------------

From gmt  Tue May  1 09:16:52 1990
Received: from owl.cs.arizona.edu by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP
    id AA22025; Tue, 1 May 90 09:16:52 MST
Date: Tue, 1 May 90 09:16:47 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by owl.cs.arizona.edu; Tue, 1 May 90 09:16:47 MST
To: [e-mail], info-sr
Subject: Re:  Casting with pointers and type sizes

    Is it possible in SR to say ADDR(X), where X is and int and ADDR
    is a pointer ?

No.  If I understand what you're trying to do, the best way right now
is assign "ADDR + X" to another variable Y, and then reference "Y^".

    Also, what is the mechanism for finding out the size of a type ?

There isn't one, but you can allocate variables of a type via "new()"
without knowing the type's size, if that helps.

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    [phone]     [e-mail]     110 57 16 W / 32 13 45 N / +758m

From ntmtv![e-mail]  Tue May  1 11:31:58 1990
From: ntmtv![e-mail]
Received: from ames.arc.nasa.gov by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP
    id AA01512; Tue, 1 May 90 11:31:58 MST
Received: by ames.arc.nasa.gov (5.61/1.2); Tue, 1 May 90 11:31:46 -0700
Received: by ntmtv.com (3.2/SMI-3.2)
    id AA01553; Tue, 1 May 90 11:00:21 PDT
Date: Tue, 1 May 90 11:00:21 PDT
Message-Id: <[e-mail]>
To: ames![e-mail], ames![e-mail]

Received: from alpet.ntmtv.com by ntmtv.com (3.2/SMI-3.2)
    id AA01546; Tue, 1 May 90 11:00:18 PDT
Received: by alpet.ntmtv.com (4.0/SMI-4.0)
    id AA05546; Tue, 1 May 90 10:57:26 PDT
Date: Tue, 1 May 90 10:57:26 PDT
From: hildum@alpet (Eric Hildum)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  Porting SR to a Motorola System V/68
Cc: [e-mail]

Gregg,

We have recently received a new Motorola system, with their next release of
UNIX. It appears slightly different, in that the socket library is now included
in the c library as is done with 4.x systems.  This means that the changes I
made to incorporate the library "inet" are no longer needed.  I have been
a little busy of late, so have not been able to come up with a new differences
file for you.  I will send my changes as soon as possible.

                Eric Hildum

From [e-mail]  Tue May  1 23:09:24 1990
Received: from munnari.OZ.AU by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP
    id AA17410; Tue, 1 May 90 23:09:24 MST
Received: from batserver.cs.uq.oz (via metro) by munnari.oz.au with SunIII (5.61+IDA+MU)
    id AA04649; Wed, 2 May 1990 16:09:15 +1000
    (from [e-mail] for [e-mail])
Message-Id: <9005020043.AA25850@client>
To: [e-mail]
Subject: Re: Casting with pointers and type sizes
In-Reply-To: Your message of Tue, 01 May 90 09:16:47 -0700.
             <[e-mail]>
Date: Wed, 02 May 90 10:43:52 +1000
From: Andrew Moran <[e-mail]>


>    Is it possible in SR to say ADDR(X), where X is and int and ADDR
>    is a pointer ?

>No.  If I understand what you're trying to do, the best way right now
>is assign "ADDR + X" to another variable Y, and then reference "Y^".

Well, what I want is an equivalent to "(TYPE *) 0" actually.  I suppose "null"
works for all pointer types though, doesn't it, silly me.

>    Also, what is the mechanism for finding out the size of a type ?

>There isn't one, but you can allocate variables of a type via "new()"
>without knowing the type's size, if that helps.

I need to allocate a big block of memory once (it's a heap for an abstract
machine), so I want to know exactly the right number to give malloc.  For
example, if the elements of my heap are composed of an enum, a ref_count and
two pointers, then what is the 200000*size(heap_element) ?  Is there anyway I
can force the SR compiler to use shorts/chars or something rather than
fully-fledged ints for the first two fields ?  This reduces size(heap_element)
from 4 words to 3 -- very desirable.

Also, I'm having trouble with semaphores, specifically I wish to include a
semaphore field in a record.  This is intended to enable me to protect an
instance of a record from being fiddled with by more than more process
simultaneously (sheathing the "fiddling" code isn't enough, I want to make the
elements critical, not the whole structure).

>  Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
>  [phone]     [e-mail]     110 57 16 W / 32 13 45 N / +758m

Angst

-------------
"The eyes are open, the mouth moves, but Mr. Brain has long since departed,
 hasn't he Percy" --- Lord Edmund BlackAdder, to Lord Percy Percy.
-------------------

From gmt  Wed May  2 19:10:30 1990
Received: from owl.cs.arizona.edu by megaron (5.59-1.7/15) via SMTP
    id AA19317; Wed, 2 May 90 19:10:30 MST
Date: Wed, 2 May 90 16:11:49 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by owl.cs.arizona.edu; Wed, 2 May 90 16:11:49 MST
To: [e-mail]
Subject: Re: Casting with pointers and type sizes
Cc: info-sr

    From: Andrew Moran <[e-mail]>

    I need to allocate a big block of memory once (it's a heap for an abstract
    machine), so I want to know exactly the right number to give malloc.  For
    example, if the elements of my heap are composed of an enum, a ref_count
    and two pointers, then what is the 200000*size(heap_element) ?

The easiest way to do something like this in SR is to let the system
figure it all out and allocate it, e.g.:

        type t = rec (
        e : enum ( red, green, blue )
        r : int
        p : ptr t
        q : ptr any
        )
        const n := 200000
        var a[n] : t        # declare array of 200000 records

    Is there anyway I can force the SR compiler to use shorts/chars or
    something rather than fully-fledged ints for the first two fields ?
    This reduces size(heap_element) from 4 words to 3 -- very desirable.

There's no easy way to do that.  It is possible to declare fields as chars
and explicitly convert to & from other types.  SR has no way to use shorts.

    Also, I'm having trouble with semaphores, specifically I wish to include a
    semaphore field in a record.  This is intended to enable me to protect an
    instance of a record from being fiddled with by more than more process
    simultaneously (sheathing the "fiddling" code isn't enough, I want to make
    the elements critical, not the whole structure).

This is also tricky.  An SR semaphore declares an op, not a variable, so
semaphores can't be used in records.  One approach would be to have an
"array" of semaphores, then associate a different one with each record
(perhaps by storing a unique semaphore index in the record).

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    [phone]     [e-mail]     110 57 16 W / 32 13 45 N / +758m

From [e-mail]  Sat Jun 23 01:35:24 1990
Received: from munnari.oz.au by megaron (5.61/15) via SMTP
    id AA09579; Sat, 23 Jun 90 01:35:24 -0700
Received: from batserver.cs.uq.oz (via metro) by munnari.oz.au with SunIII (5.61+IDA+MU)
    id AA02222; Sat, 23 Jun 1990 18:35:08 +1000
    (from [e-mail] for [e-mail])
Message-Id: <9006210724.AA06496@client>
To: [e-mail]
Subject: How are enumerated types represented + process priority
Date: Thu, 21 Jun 90 17:24:19 +1000
From: Andrew Moran <[e-mail]>


Is a variable of an enumerated type the same size as an int or do they fit into
chars ?  Can I cast an enum to a char ?

Can I influence the priority of a process ?

Angst

----------
"Tell the King that he's as safe as a fox being hunted by a pack of one-legged
 hunting tortoises." -- Lord Edmund Blackadder, loyalist
-----------------

From gmt  Mon Jun 25 07:21:09 1990
Received: from owl.cs.arizona.edu by megaron (5.61/15) via SMTP
    id AA07136; Mon, 25 Jun 90 07:21:09 -0700
Date: Mon, 25 Jun 90 07:21:05 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by owl.cs.arizona.edu; Mon, 25 Jun 90 07:21:05 MST
To: info-sr
Subject: Re:  How are enumerated types represented + process priority

    Date: Thu, 21 Jun 90 17:24:19 +1000
    From: Andrew Moran <[e-mail]>

    Is a variable of an enumerated type the same size as an int or do they
    fit into chars ?

SR always stores enums as ints, at least right now.  (Nothing is promised.)

    Can I cast an enum to a char ?

Yes, and vice versa.

    Can I influence the priority of a process ?

Not yet, but we're working on it.

Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
[phone]     [e-mail]     110 57 16 W / 32 13 45 N / +758m

From [e-mail]  Sat Aug 18 15:17:59 1990
Received: from ALPHA.IS.TCU.EDU ([129.117.15.2]) by megaron (5.61/15) via SMTP
    id AA23903; Sat, 18 Aug 90 15:17:59 -0700
Received: from tcucs1.cs.tcu.edu. by ALPHA.IS.TCU.EDU; Sat, 18 Aug 90 17:19 CDT
Received: by tcucs1.cs.tcu.edu. (4.0/SMI-4.0) id AA03603; Sat, 18 Aug 90
 17:18:31 CDT
Date: Sat, 18 Aug 90 17:18:31 CDT
From: [e-mail]
Subject: srx lost connection???
To: [e-mail]
Message-Id: <[e-mail].>
X-Envelope-To: [e-mail]

A week ago we came online to internet.  Before that time, we had no problem
running SR programs across our local network of SUN3s and SparcStations
(provided that the main resource was run on a SparcStation).  Now we
are getting errors of the form:

   srx: lost connection to virtual machine <vm number>

when we try start up a vm on a SUN3 from a main resource running on a
SparcStation.  This message gets generated even when running the
simple program in sr/examples/remote.

Does anyone know if this problem is resolvable or what is causing it?  We
currently are not running yellow pages, we do not have a local nameserver
and we are not running in.routed (a router is specified using "route" in
rc.local).

Thanks in advance for you help!!!

Craig Morgenstern
Dept of Computer Science
Texas Christian University
[e-mail]

From [e-mail]  Sat Aug 18 21:58:34 1990
Received: from ALPHA.IS.TCU.EDU ([129.117.15.2]) by megaron (5.61/15) via SMTP
    id AA02785; Sat, 18 Aug 90 21:58:34 -0700
Received: from tcucs1.cs.tcu.edu. by ALPHA.IS.TCU.EDU; Sun, 19 Aug 90 00:00 CDT
Received: by tcucs1.cs.tcu.edu. (4.0/SMI-4.0) id AA04591; Sat, 18 Aug 90
 23:59:06 CDT
Date: Sat, 18 Aug 90 23:59:06 CDT
From: [e-mail]
Subject: srx lost connection
To: [e-mail]
Message-Id: <[e-mail].>
X-Envelope-To: [e-mail]

Please ignore my last request for help.  We seem to be having network
problems not specific to SR on our SparcStations.

Craig Morgenstern
[e-mail]

From [e-mail]  Wed Oct 10 21:29:28 1990
Received: from munnari.oz.au by megaron.cs.arizona.edu (5.61/15) via SMTP
    id AA01197; Wed, 10 Oct 90 21:29:28 -0700
Received: from batserver.cs.uq.oz (via metro) by munnari.oz.au with SunIII (5.64+1.3.1+0.50)
    id AA25628; Thu, 11 Oct 1990 14:29:18 +1000
    (from [e-mail] for [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Can operation capabilities be included in records ?  Semaphores ?
Date: Thu, 11 Oct 90 14:19:04 +1000
From: Andrew Moran <[e-mail]>


I am trying to gain mutual exclusion over elements of a data type (i.e. no
simulaneous operations on any instance of the data type).  To this end, I would
like to include in the data type a semaphore (rather, an operation capability
that mimics a semaphore since semaphores cannot be variables as far as I can
tell).  I've run into quite a few problems when trying to initialise an
instance.

Assume the following declarations.

    optype LockSem ()

    type SemRec = rec (data_bits : Data; lock : cap LockSem)

    op new_semrec (data : Data) returns sr : Sem Rec

The lock field is intended to be the means of exclusion.  When I want to
change/access the record I use "receive lock ()"; when I want to release the
lock I use "send lock ()".  Is there any way I can actually meaningfully assign
to the lock field ? I've tried

    proc new_semrec (data) returns sr
        sr := new(SemRec)
        sr^.data := data

        op lock_sem : LockSem
        sr^.lock := lock_sem
        send sr^.lock () /* So the record can be used immediately */
    end new_semrec

but, as common sense would dictate, this doesn't work since lock_sem has not
been implemented.

Is there any way around this Gregg ?  Or have I overstepped the bounds of
decent SR programming.

Andrew Moran

---------
"He's mad, totally mad.  He's madder than Mad Jack McMad, winner of last year's
 Mr. Madman competition." -- Edmund, a butler.
----------------

From [e-mail]  Tue Oct 16 13:30:03 1990
Received: from iris.eecs.ucdavis.edu by megaron.cs.arizona.edu (5.61/15) via SMTP
    id AA01141; Tue, 16 Oct 90 13:30:03 -0700
Received: by iris.eecs.ucdavis.edu (5.57/UCD.EECS.3.0)
    id AA12512; Tue, 16 Oct 90 13:29:44 -0700
Received: by ivy (5.57/3.14)
    id AA04050; Tue, 16 Oct 90 13:29:21 -0700
Date: Tue, 16 Oct 90 13:29:21 -0700
From: [e-mail] (Ron Olsson)
Message-Id: <9010162029.AA04050@ivy>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: Andrew Moran's message of Thu, 11 Oct 90 14:19:04 +1000 <[e-mail]>
Subject: Can operation capabilities be included in records ?  Semaphores ?

   Date: Thu, 11 Oct 90 14:19:04 +1000
   From: Andrew Moran <[e-mail]>
   ...  The lock field is intended to be the means of exclusion.  When
   I want to change/access the record I use "receive lock ()"; when I
   want to release the lock I use "send lock ()".  Is there any way I
   can actually meaningfully assign to the lock field ? I've tried

       proc new_semrec (data) returns sr
           sr := new(SemRec)
           sr^.data := data
           op lock_sem : LockSem
           sr^.lock := lock_sem
           send sr^.lock () /* So the record can be used immediately */
       end new_semrec

   but, as common sense would dictate, this doesn't work since
   lock_sem has not been implemented.

Right.  A general way to solve this is something like:

       proc new_semrec (data) returns sr
           sr := new(SemRec)
           sr^.data := data
           op req_lock, rel_lock : LockSem
           sr^.req_lock := req_lock
           sr^.rel_lock := rel_lock
           reply
                   do true -> receive req_lock(); receive rel_lock();  od
       end new_semrec

I've changed the interface to
    call sr^.req_lock(); /* use sr */; send sr^.rel_lock()
(And not shown, but obvious, the decl of SemRec.)  I'm not sure,
though, that you didn't already figure out this kind of solution but
were looking for a better way, one that uses your interface. Note that
each new_semrec process hangs around forever -- that can be tidied up
if you know when no one will use the record anymore.

If all the processes using the record are in the same resource
instance and you can bound the number of records that will ever be in
existence at once, then you might want to use an array of shared
operations.  That would allow you to use the interface you want, e.g.,
    receive lock[sr^.i]; /* use sr */; send lock[sr^.i()]
where the index i is assigned by new_semrec.

If using processes are outside the resource, you can provide procs in
the resource they can call to do the receive/send on their behalf.

From [e-mail]  Tue Oct 16 16:49:15 1990
Received: from munnari.oz.au by megaron.cs.arizona.edu (5.61/15) via SMTP
    id AA11550; Tue, 16 Oct 90 16:49:15 -0700
Received: from batserver.cs.uq.oz (via metro) by munnari.oz.au with SunIII (5.64+1.3.1+0.50)
    id AA08353; Wed, 17 Oct 1990 09:49:01 +1000
    (from [e-mail] for [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Ron Olsson's reply to "Can operation capabilities .... "
In-Reply-To: Your message of "Tue, 16 Oct 90 13:29:21 MST."
             <9010162029.AA04050@ivy>
Date: Wed, 17 Oct 90 09:14:05 +1000
From: Andrew Moran <[e-mail]>


> Right.  A general way to solve this is something like:
>
>        proc new_semrec (data) returns sr
>            sr := new(SemRec)
>            sr^.data := data
>            op req_lock, rel_lock : LockSem
>            sr^.req_lock := req_lock
>            sr^.rel_lock := rel_lock
>            reply
>                  do true -> receive req_lock(); receive rel_lock();  od
>        end new_semrec

Thanks Ron, good stuff.  I thought some kind of "reply then wait for
invocations" structure would be required, I just couldn't get it to mesh.

> I've changed the interface to
>     call sr^.req_lock(); /* use sr */; send sr^.rel_lock()

Fine, suits me fine.  You see I want to lock elements of the heap of a parallel
functional abstract machine (for evaluation).  I will know when a heap element
is not used anymore, but the usual response is to add it to the free list.
This will mean the new_semrec (new_cell actually) process will still be alive.
If I do away with the free list, I can be rid of the new_cell process.

However, this is merely a prototype of the abstract machine, in which the
memory management (particularly allocation of heap space) is very
unsophisticated (i.e. uses "new", rather than allocating explicitly from a heap
as all responsible abstract machines do).  If I rid myself of the free list
now, it will make the step from prototype to real machine much more difficult.

Anyway, at the moment the only benefit gained from having a free list is that
you don't need to call new_cell (I think the new(CELL) is the time-consuming
procedure) thus saving some time.  But with the process hanging around, I'm
wondering what the time/space cost will be.  Also, it is likely that there will
be large numbers of these new_cell processes simultaneously active.  Is there
some limit to the number of active SR processes I can have at one time ?  What
about the speed (and space) degradation involved in having heaps of Sr
processes running about ?

> If all the processes using the record are in the same resource
> instance and you can bound the number of records that will ever be in
> existence at once, then you might want to use an array of shared
> operations.  That would allow you to use the interface you want, e.g.,
>     receive lock[sr^.i]; /* use sr */; send lock[sr^.i()]
> where the index i is assigned by new_semrec.

The using processes will never be in the same resource, and the bound on the
heap size is huge (even though it is not enforced in the prototype).  I don't
like the idea of an array of 100 000 operations.  A "free list" of shared
operations, perhaps ?  That's the same as keeping the free list of heap
elements with operation attached to each element.  Back to square one.

> If using processes are outside the resource, you can provide procs in
> the resource they can call to do the receive/send on their behalf.

Yep.

What Ron has suggested is what I was after, the only question that now remains
is "to free or not to free ?"  That is, should I keep the free list as it is
(enabling easy extension of the prototype) or will I be forced (for performance
considerations) to abandon it ?

To summarize, these are now the question of interest:

    1. What does it cost in time and space to have an SR process active
       (waiting for the most part) throughout execution of the program ?
    2. How many SR processes may be active simultaneously ?
    3. What sort of performance degradation can I expect as the number of
       active SR processes increases ?

Thanks people,

Angst

---------------
Left. G: "Sir, what do we do if we stand on a mine ?"
Capt. B: "Well, normal procedure, Leftenant, is to jump 200 feet into the air
      and scatter oneself over a wide area."

    -- somewhere no man's land, "Blackadder Goes Forth"
---------------

From [e-mail]  Wed Oct 17 11:35:58 1990
Received: from iris.eecs.ucdavis.edu by megaron.cs.arizona.edu (5.61/15) via SMTP
    id AA22341; Wed, 17 Oct 90 11:35:58 -0700
Received: by iris.eecs.ucdavis.edu (5.57/UCD.EECS.3.0)
    id AA13975; Wed, 17 Oct 90 11:35:55 -0700
Received: by ivy (5.57/3.14)
    id AA08117; Wed, 17 Oct 90 11:35:53 -0700
Date: Wed, 17 Oct 90 11:35:53 -0700
From: [e-mail] (Ron Olsson)
Message-Id: <9010171835.AA08117@ivy>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: Andrew Moran's message of Wed, 17 Oct 90 09:14:05 +1000 <[e-mail]>
Subject: Ron Olsson's reply to "Can operation capabilities .... "

   Date: Wed, 17 Oct 90 09:14:05 +1000
   From: Andrew Moran <[e-mail]>

   ...
   To summarize, these are now the question of interest:

   1. What does it cost in time and space to have an SR process active
      (waiting for the most part) throughout execution of the program ?
   2. How many SR processes may be active simultaneously ?
   3. What sort of performance degradation can I expect as the number of
      active SR processes increases ?

The max number of processes per vm is bounded.  `srl -l' will list the
limits, and the srl options that control them.  Each process takes
space for stack (also controllable via srl option).  So, memory to
hold program can get large if you have lots of processes.  However,
that shouldn't affect execution time (other than perhaps for
swapping...).  You might run out of virtual memory if you have
thousands of processes.

BTW, another technique that you might find relevant is to use an SR
operation to implement your free list.  To obtain an item, receive
from the operation; to release an item, send it to the operation.  Of
course, the receiver must be in the same resource (but a proc to
service outside requests could do the dirty work).  The SR paper in
TOPLAS Jan 88 contains a paragraph describing this technique (page 82,
"data-containing semaphores").  I've recently written a paper that
describes it in more detail; I'll mail you a copy if you're
interested.  I don't think this technique will solve your original
problem -- you want locking, which seems to indicate that you have
multiple processes accessing the same record; this technique allows
one process at a time to use an item, and then return it.  But the
idea might help you in some other aspect of your work.

From @CUNYVM.CUNY.EDU:[e-mail]  Wed Nov 21 05:13:18 1990
Resent-From: @CUNYVM.CUNY.EDU:[e-mail]
Received: from Arizona.edu (Hopey.Telcom.Arizona.EDU) by megaron.cs.arizona.edu (5.61/15) via SMTP
    id AA22004; Wed, 21 Nov 90 05:13:18 -0700
Return-Path: [e-mail]
Received: from cunyvm.cuny.edu by Arizona.edu; Wed, 21 Nov 90 05:12 MST
Received: from TAURUS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with
 BSMTP id 7719; Wed, 21 Nov 90 07:11:37 EST
Received: from s2.math.tau.ac.il by math.tau.ac.il (4.1/TAU-4.8) id AA07621;
 Wed, 21 Nov 90 14:12:37 +0200
Received: by s2.math.tau.ac.il (4.1/TAUCLNT-2.0) id AA00615; Wed, 21 Nov 90
 14:10:29 +0200
Resent-Date: Wed, 21 Nov 90 05:13 MST
Date: Wed, 21 Nov 90 14:10:29 +0200
From: [e-mail]
From: [e-mail]
Subject: SSR on Transputers
Resent-To: [e-mail]
To: [e-mail]
Reply-To: [e-mail]
Resent-Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Envelope-To: [e-mail]
X-Vms-To: [e-mail]
Comments: If you have trouble reaching this host as math.tau.ac.il Please use
 the old address: [e-mail]

I would like to know if someone has ported SR to a transputer network
running the Helios Operating System?


Fernando Libedinsky
CS Dept, Tel-Aviv University
[e-mail]